STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/T0501/text0035.txt

Text File | 1997-02-06 | 3.6 KB | 73 lines

I noticed a mail in here discussing the possibility of adding / replacing
graphics in IWAD files themselves without the usual PWAD restrictions (floor
tiles, sprites, samples etc).

Since Anthony is working on the WAD edit stuff, and I have a working knowledge
of loading IWADs and processing them etc, I was thinking there might be a way to
handle entire IWADs in a single PWAD for future versions of BM. Distributing
truly custom levels on the PC is already made very difficult because of the
problems PWAD files have with sprites and other data, so fixing this would be a
great bonus.

As far as I can tell, the only reason PWAD files are possible in the first place
is down to specific 'inconsistencies' with the way Doom keeps track of the
resources themselves when loaded from disk and when organizing / preprocessing
textures in memory etc.

The problem is that each resource 'type' (tile, picture, sample, sprite etc.)
must be placed BETWEEN two special 'markers' in the IWAD file. Some example
markers are as follows:

Patch graphics:    P_START,P_END
Floor graphics:    F_START,F_END
Sprites:        S_START,S_END

..and so on for each 'type' of resource in the IWAD. The markers themselves are
0-byte files with no purpose other than to mark the beginning & end of a
specific section.

If a resource of any given type is NOT found between the markers, there is a
VERY good chance Doom will not recognise the resource and report it missing, or
even crash.

So why do PWADs allow some types but not others? Well, for a start, there are a
number of WAD entries which do not have markers, and tend to come at the start
of the WAD. These include things like level data. However, PWAD files DO support
wall textures - but NOT floor textures - UNLESS you include ALL floors at once!

The floors can be explained by the fact that unless you include ALL floors,
along with the F_START & F_END markers, the data will be put in the wrong place,
or will not overwrite the data in the original IWAD when patched into RAM. The
result is either a disorganized set of floor tiles, or two copies of pretty much
the same thing. Doom will not cope with this and will probably crash as a
result. Sprites suffer the same way.

The only reason you can put new WALL textures in a PWAD is through sheer
accident - there is a second directory entry called PNAMES which has a record of
every patch graphic (wall texture fragment) in the WAD. No matter where the
patches are stored, the Doom engine can still find them with this PNAMES
directory - even if the patches don't fall between P_START & P_END. In other
words, Doom uses an alternative method for keeping track of patch graphics - and
ignores P_START & P_END for search operations.

So if Doom needed to pre-process it's sprites & floor textures before use, with
the help of a SNAMES & FNAMES record list, as it already does with PNAMES for
the walls - then we wouldn't have to worry about ?_START & ?_END rubbish and we
could stick as much in the PWAD as we want by just fabricating new FNAMES &
SNAMES resources and sticking them in the PWAD too. But we can't.

By making some simple modifications to the BM WAD handler, we can force BM to
make use of home-made SNAMES & PNAMES directories to find all floor, wall,
sprite & sample resources and therefore be able to ignore the start/end marker
restrictions. These directories could even just be a list of names of all the
new sprites or floors in the PWAD - you could ignore the names of those already
in the IWAD.

If anyone want's to check this all out, refer to the Doomspec.txt guide on one
of the FTP sites. This is where I get most of my information, although much of
it is guesswork and experimentation.

Doug.